Repository navigation
Conversation
…he input On iOS, an input inside a ScrollView with keyboardDismissMode="on-drag" focused itself again after a short drag that started on it. The drag dismissed the keyboard, but the input kept the JS responder. The release then counted as a press, and a press focuses the input. The input now tracks how far the touch moves from where it went down. After more than 10 points the press no longer focuses the input, also when the finger comes back to where it started. onPress still fires. A drag on an unfocused input no longer focuses it either. React Native's TextInput focuses itself in the same case, so this is a deliberate difference from it. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
…r a drag The story puts the enriched input and React Native's TextInput in a ScrollView with keyboardDismissMode="on-drag" and shows a focus and blur count for each. A short drag that starts on the enriched input must leave its focus count unchanged. Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
jnowakow
reviewed
Nov 12, 2026
jnowakow
left a comment
jnowakow
left a comment
Collaborator
There was a problem hiding this comment.
The re-focus comes from the JS focusTextInput call in onPress, not from UIKit. The threshold adds a second tap-vs-drag check on top of UIKit's, and the two can still disagree, since 10 pt isn't UIKit's threshold.
An alternative: let the native view be the only thing that decides for touches inside the input, and keep the JS focus for the hitSlop area, which is what it was added for.
- JS: in
onResponderGrant, note whether the touch went down outside the view's bounds (size fromonLayout), and only then callfocusTextInputinonPress. - iOS:
RCTViewComponentViewsizes the content view to the frame minus padding, so taps on the padding never reach theUITextView. This sends them there, likeTextInput, which keeps padding intextContainerInset:
- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event
{
UIView *hitView = [super hitTest:point withEvent:event];
if (hitView == self && CGRectContainsPoint(self.bounds, point)) {
return _textView;
}
return hitView;
}I tried it on the iOS simulator with your regression story: a short drag on the text or the padding leaves the keyboard dismissed, and taps on both still focus. Trade-offs: it's a native change, and a drag that starts in the hitSlop area still re-focuses.
What do you think?
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What/Why?
Fixes #1158.
On iOS, an
EnrichedMarkdownTextInputinside aScrollViewwithkeyboardDismissMode="on-drag"focused itself again after a short drag that started on it. The keyboard closed and came straight back.This is a regression from #884, which gave the input React Native's press handling:
rejectResponderTerminationdefaults totrue.The input now tracks how far the touch moves from where it went down. After more than 10 points, the press no longer focuses the input, also when the finger comes back to where it started.
onPressstill fires. A drag that starts on an unfocused input no longer focuses it either.Notes for review:
TextInputuses the same press config and re-focuses in the same case (checked with a multilineTextInputon RN 0.88). This PR is a deliberate difference from it.onResponderGrant, not inonPressIn. Pressability callsonPressInagain when the finger re-enters the press area, so a reset there would treat "drag out and come back" as a new tap.Regressioncategory to the input stories, with a story that reproduces the issue.Testing
New jest test,
__tests__/input-press-focus.test.tsx. It covers taps, short drags, a drag that returns to its start, and a drag that leaves the press area and comes back. Four of its eight cases fail onmain.By hand in the example app: Storybook →
EnrichedMarkdownTextInput→ Regression → "Keyboard Dismiss On Drag ([iOS] Input re-focuses after a short drag in a ScrollView with keyboardDismissMode="on-drag" #1158)".focus 1 · blur 1. Onmainit readsfocus 2 · blur 1and the keyboard comes back.The story also has a React Native
TextInput, which still re-focuses, for comparison.Run on the iOS 26.0 simulator on an earlier revision of the fix. The final revision is covered by the jest test. Not run on Android.
Screen recordings
ScreenRecording_11-12-2026.11-00-29_1.MP4
ScreenRecording_11-12-2026.11-01-14_1.MP4
PR Checklist